# RBAC (역할 기반 접근 제어)

## 1. 개요
**RBAC(Role-Based Access Control, 역할 기반 접근 제어)**는 사용자의 개별 신원이 아닌, 조직 내에서 수행하는 '역할(Role)'에 따라 시스템 자원에 대한 접근 권한을 부여하는 보안 모델이다.

전통적인 접근 제어 방식인 **DAC(Discretionary Access Control, 임의적 접근 제어)**는 자원 소유자가 임의로 권한을 부여하므로 관리가 파편화되고 보안 취약점이 발생하기 쉽다. 반면, **MAC(Mandatory Access Control, 강제적 접근 제어)**는 시스템이 정한 엄격한 보안 등급에 따라 접근을 통제하여 매우 안전하지만, 설정이 복잡하고 유연성이 떨어진다는 단점이 있다. RBAC는 이러한 두 모델의 절충안으로서, 권한 관리를 '역할'이라는 추상화된 계층으로 통합함으로써 대규모 조직에서도 효율적이고 일관된 보안 정책을 적용할 수 있도록 설계되었다.

## 2. 동작 원리 및 구조
RBAC의 핵심은 사용자에게 직접 권한을 부여하지 않고, **사용자 $\rightarrow$ 역할 $\rightarrow$ 권한**으로 이어지는 간접 할당 구조를 사용하는 것이다.

### 2.1 권한 할당 프로세스
권한 부여 과정은 다음과 같은 논리적 흐름을 따른다.
`사용자(User)` $\xrightarrow{할당}$ `역할(Role)` $\xrightarrow{부여}$ `권한(Permission)` $\rightarrow$ `[자원(Object)에 대한 작업(Operation)]`

**[권한 할당 다이어그램]**
```mermaid
graph LR
    U1[사용자 A] --> R1[팀장 역할]
    U2[사용자 B] --> R1[팀장 역할]
    U3[사용자 C] --> R2[팀원 역할]
    
    R1 --> P1[문서 읽기/쓰기/삭제]
    R1 --> P2[결재 승인]
    R2 --> P1[문서 읽기/쓰기]
```

### 2.2 매핑 테이블 예시
다음은 실제 시스템에서 구현될 때의 논리적 매핑 구조이다.

| 사용자 (User) | 할당된 역할 (Role) | 역할별 권한 (Permission) | 접근 가능 자원 (Resource) |
| :--- | :--- | :--- | :--- |
| 김철수 | 관리자 (Admin) | 모든 권한 (Full Access) | 시스템 전체 설정, 사용자 계정 |
| 이영희 | 편집자 (Editor) | 읽기, 수정, 게시 | 콘텐츠 DB, 게시판 |
| 박지민 | 뷰어 (Viewer) | 읽기 전용 (Read-only) | 공개 게시물, 공지사항 |

## 3. RBAC의 주요 모델 및 계층
RBAC는 요구사항의 복잡도에 따라 여러 단계의 모델로 발전해 왔다.

### 3.1 모델별 특징 비교
| 모델 | 주요 특징 | 핵심 개념 | 비고 |
| :--- | :--- | :--- | :--- |
| **Core RBAC (RBAC0)** | 가장 기본적인 형태 | 사용자-역할-권한의 단순 매핑 | 기본 권한 관리 |
| **Hierarchical RBAC (RBAC1)** | 역할 간의 상속 관계 도입 | 상위 역할이 하위 역할의 권한을 포함 | 조직도 반영 가능 |
| **Constrained RBAC (RBAC2)** | 역할 수행에 제약 조건 추가 | 상호 배제(SoD), 시간 제한 등 | 보안 강화 및 부정 방지 |

*참고: **RBAC3**는 위 세 가지 모델(RBAC0, RBAC1, RBAC2)의 모든 특성을 통합한 완전한 모델을 의미한다.*

- **계층적 RBAC (Hierarchical RBAC):** 예를 들어 '팀장' 역할은 '팀원' 역할이 가진 모든 권한을 자동으로 상속받으며, 추가적으로 '결재 권한'을 더 갖는 구조이다.
- **제약 조건 RBAC (Constrained RBAC):** **SoD(Separation of Duties, 직무 분리)** 개념이 적용된다. 예를 들어, '결제 요청자' 역할과 '결제 승인자' 역할을 한 사람이 동시에 가질 수 없도록 제한하여 내부 부정행위를 방지한다.

## 4. RBAC의 장점과 한계

### 4.1 장점
1. **관리 효율성:** 수천 명의 사용자에게 개별 권한을 부여하는 대신, 몇 개의 역할만 정의하여 할당하면 되므로 관리 비용이 획기적으로 감소한다.
2. **보안성 향상:** '최소 권한 원칙(Principle of Least Privilege)'을 적용하기 쉬우며, 인사 이동 시 역할만 변경하면 즉시 권한이 갱신된다.
3. **규정 준수(Compliance):** 누가 어떤 역할을 통해 어떤 권한을 가졌는지 명확히 감사(Audit)할 수 있다.

### 4.2 한계: 역할 폭발 (Role Explosion)
RBAC의 가장 큰 운영상 한계는 **역할 폭발(Role Explosion)** 현상이다. 이는 세부적인 권한 제어가 필요해질수록 역할의 수가 기하급수적으로 늘어나는 현상을 말한다.

**[역할 폭발 예시]**
- 서울 지점 $\times$ 영업팀 $\times$ 대리
- 부산 지점 $\times$ 영업팀 $\times$ 대리
- 서울 지점 $\times$ 인사팀 $\times$ 대리
$\rightarrow$ **위와 같이 지역, 부서, 직급의 모든 조합마다 새로운 역할을 생성해야 하는 상황**

### 4.3 역할 폭발 해결 방안
역할 폭발을 방지하기 위해 다음과 같은 전략을 사용한다.
- **역할 계층화:** 공통 권한을 하위 역할로 묶고 상위 역할이 이를 상속받게 하여 중복 정의를 줄인다.
- **매개변수화된 역할:** 역할에 변수(예: 지역, 부서)를 도입하여 하나의 역할 정의로 여러 상황에 대응한다.
- **ABAC로의 전환:** 정적인 역할 대신 동적인 속성(Attribute) 기반 제어를 혼합하여 사용한다.

## 5. 실제 구현 및 활용 사례

### 5.1 활용 사례
- **클라우드 서비스 (AWS IAM):** AWS에서는 'IAM Role'을 통해 EC2 인스턴스나 Lambda 함수에 특정 권한 세트를 부여하여 서비스 간 안전한 통신을 구현한다.
- **기업 인사 시스템:** 신입 사원 입사 시 '사원' 역할을 부여하고, 승진 시 '과장' 역할로 변경함으로써 접근 가능한 결재 라인과 문서를 자동으로 제어한다.
- **Kubernetes (K8s):** `ClusterRole`과 `RoleBinding`을 통해 클러스터 내 리소스(Pod, Service 등)에 대한 접근 권한을 제어한다.

### 5.2 설정 예시 (YAML 형식)
다음은 Kubernetes 스타일의 역할 정의 및 할당 예시이다.

```yaml
# 1. 역할 정의 (Role Definition)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""] 
  resources: ["pods"]
  verbs: ["get", "watch", "list"] # 리소스에 대해 수행 가능한 작업 (get: 단일 조회, list: 목록 조회 등)

---
# 2. 역할 할당 (Role Binding)
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-user
subjects:
- kind: User
  name: "alice@company.com" # 사용자 Alice에게
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader # 위에서 정의한 pod-reader 역할 할당
  apiGroup: rbac.authorization.k8s.io
```

### 5.3 DB 스키마 설계 예시
RBAC를 데이터베이스로 구현할 때는 일반적으로 다음과 같은 다대다(N:M) 관계의 테이블 구조를 설계한다.

- **Users**: 사용자 정보 (`user_id`, `username`, `email`)
- **Roles**: 역할 정의 (`role_id`, `role_name`, `description`)
- **Permissions**: 세부 권한 (`perm_id`, `perm_name`, `resource`, `action`)
- **User_Roles**: 사용자-역할 매핑 (`user_id`, `role_id`)
- **Role_Permissions**: 역할-권한 매핑 (`role_id`, `perm_id`)

## 6. 관련 개념 및 발전 방향

### 6.1 RBAC vs ABAC
RBAC의 정적인 한계를 극복하기 위해 **ABAC(Attribute-Based Access Control, 속성 기반 접근 제어)**가 등장하였다.

| 구분 | RBAC (역할 기반) | ABAC (속성 기반) |
| :--- | :--- | :--- |
| **판단 기준** | 사용자가 어떤 **역할**인가? | 사용자의 **속성**이 무엇인가? |
| **제어 요소** | 역할 (Role) | 사용자, 자원, 환경 속성 (Attribute) |
| **유연성** | 낮음 (역할 변경 필요) | 높음 (조건식으로 제어 가능) |
| **복잡도** | 낮음 (설계가 단순함) | 높음 (정책 엔진 필요) |
| **예시** | "관리자는 모든 파일을 읽을 수 있다." | "인사팀 소속이며, 근무 시간 내에, 서울 IP로 접속한 사용자만 읽을 수 있다." |

### 6.2 현대적 트렌드
최근의 보안 트렌드는 **제로 트러스트(Zero Trust)** 모델로 이동하고 있다. 단순히 역할이 맞다고 해서 신뢰하는 것이 아니라, 접속할 때마다 사용자의 기기 상태, 접속 위치, 인증 수준 등 다양한 속성을 실시간으로 검증하는 **RBAC와 ABAC의 하이브리드 모델**이 주를 이루고 있다.

## RBAC 모델별 실제 적용 사례
이론적인 RBAC 모델은 비즈니스 요구사항의 복잡도에 따라 다음과 같이 실제 서비스에 적용된다.

| 모델 | 적용 서비스 사례 | 비즈니스 요구사항 매칭 |
| :--- | :--- | :--- |
| **RBAC0 (Core)** | **소규모 커뮤니티, 단순 SaaS** | '관리자-편집자-일반사용자'와 같이 역할 간의 위계가 없고 권한 집합이 명확히 분리된 단순 서비스 |
| **RBAC1 (Hierarchical)** | **기업 ERP, 조직도 기반 그룹웨어** | '사원 $\rightarrow$ 대리 $\rightarrow$ 과장 $\rightarrow$ 부장'으로 이어지는 직급 체계처럼, 상위 직급이 하위 직급의 모든 권한을 포함해야 하는 조직 구조 |
| **RBAC2 (Constrained)** | **금융 시스템, 공공기관 결재 시스템** | '기안자'와 '승인자'를 엄격히 분리하여 부정 결제를 방지해야 하는 SoD(직무 분리) 필수 환경 |
| **RBAC3 (Full)** | **대규모 클라우드 플랫폼 (AWS, Azure)** | 복잡한 조직 계층(Hierarchical)과 엄격한 보안 제약(Constrained)이 동시에 필요한 엔터프라이즈급 인프라 관리 |

## 역할 폭발의 심층 원인과 리스크
역할 폭발(Role Explosion)은 단순히 역할의 수가 늘어나는 현상을 넘어, **'정적 할당의 한계'**라는 구조적 결함에서 기인한다.

### 2.1 근본 원인: 정적 매핑의 한계
RBAC는 `역할 = 권한의 집합`이라는 정적인 정의를 가진다. 하지만 실제 비즈니스 환경에서는 권한이 **[역할 $\times$ 지역 $\times$ 부서 $\times$ 프로젝트]**와 같이 여러 차원의 속성(Attribute) 조합으로 결정된다. RBAC로 이를 구현하려면 모든 가능한 조합(Cartesian Product)에 대해 개별 역할을 생성해야 하므로, 속성이 추가될 때마다 역할의 수가 기하급수적으로 증가하게 된다.

### 2.2 관리적 부채 및 보안 리스크
- **관리 복잡도 증가:** 수천 개의 역할이 생성되면 관리자는 특정 역할이 정확히 어떤 권한을 가지는지 파악하기 어려워지며, 이는 설정 오류로 이어진다.
- **권한 과잉 부여:** 적절한 역할이 정의되어 있지 않을 때, 관리 편의를 위해 사용자에게 필요 이상의 상위 역할(예: Admin)을 부여하는 경향이 발생한다.
- **감사 불능:** 역할의 명칭과 실제 권한 간의 괴리가 생겨, 보안 감사 시 실제 접근 제어 현황을 정확히 추적하기 어려워진다.

## 역할 상속 구조 및 DB 설계 확장
계층적 RBAC(Hierarchical RBAC)를 구현하기 위해서는 역할 간의 부모-자식 관계를 정의할 수 있는 구조가 필요하다.

### 5.3.1 역할 상속 ERD
```mermaid
erDiagram
    USER ||--o{ USER_ROLES : assigns
    ROLE ||--o{ USER_ROLES : "assigned to"
    ROLE ||--o{ ROLE_PERMISSIONS : contains
    PERMISSION ||--o{ ROLE_PERMISSIONS : "belongs to"
    ROLE ||--o{ ROLE : "inherits from (parent_role_id)"
```

### 5.3.2 DB 스키마 보강
기존 `Roles` 테이블에 **자기 참조 외래키(Self-Referencing Foreign Key)**를 추가하여 상속 구조를 구현한다.

- **Roles 테이블 확장**: `role_id`, `role_name`, `description`, **`parent_role_id` (FK $\rightarrow$ Roles.role_id)**
    - `parent_role_id`가 `NULL`이면 최하위 역할(Leaf Role)이다.
    - 특정 역할의 권한을 조회할 때, `parent_role_id`를 따라 최상위 역할까지 재귀적으로 쿼리하여 모든 상속 권한을 합산한다.

## RBAC의 생명주기 관리 (Role Lifecycle Management)
역할은 한 번 정의되면 고정되는 것이 아니라, 조직의 변화에 따라 생성부터 폐기까지의 생명주기를 거친다.

1. **역할 정의 및 생성 (Provisioning):** 비즈니스 프로세스 분석을 통해 필요한 최소 권한 세트를 정의하고 역할을 생성한다.
2. **역할 할당 및 검토 (Assignment & Review):** 사용자에게 역할을 부여하고, 해당 역할이 실제 직무에 적합한지 검토한다.
3. **역할 수정 및 최적화 (Modification):** 서비스 기능 변경이나 조직 개편 시 역할에 포함된 권한을 업데이트한다.
4. **역할 폐기 (Deprovisioning):** 더 이상 사용되지 않는 역할이나 중복된 역할을 제거하여 역할 폭발을 방지한다.

**[권한 과잉(Privilege Creep) 방지]**
사용자가 부서를 이동하거나 프로젝트가 변경되었음에도 이전의 역할을 그대로 유지하여 권한이 계속 누적되는 현상을 '권한 과잉'이라 한다. 이를 방지하기 위해 **정기적 권한 검토(Access Review/Attestation)** 프로세스를 도입하여, 일정 주기마다 관리자가 사용자의 역할 보유 적절성을 재승인해야 한다.

## RBAC 구현 시 고려사항 및 베스트 프랙티스

### 6.3 최소 권한 원칙의 구체적 적용
- **기본 역할(Base Role) 설정:** 모든 사용자에게 공통적으로 필요한 최소한의 권한만 가진 '기본 역할'을 정의하고, 추가 권한은 상위 역할이나 특수 역할을 통해 부여한다.
- **임시 권한 부여:** 영구적인 역할 할당 대신, 특정 작업 시간 동안만 유효한 '임시 역할'을 부여하는 메커니즘을 도입한다.

### 6.4 역할 명명 규칙 (Naming Convention)
역할의 이름만으로 성격과 범위를 파악할 수 있도록 표준화된 규칙을 수립해야 한다.
- **규칙 예시:** `[서비스/모듈]_[대상/범위]_[권한수준]`
- **구체적 적용 사례:**
    - `CRM_SALES_VIEWER`: CRM 모듈의 영업 데이터 조회자
    - `HR_PAYROLL_MANAGER`: 인사 모듈의 급여 관리자
    - `SYS_INFRA_ADMIN`: 시스템 인프라 전체 관리자
    - `BLOG_POST_EDITOR`: 블로그 게시글 편집자

### 6.5 비즈니스 프로세스 매핑 전략
역할을 설계할 때 기술적인 권한 단위가 아닌, **실제 업무 프로세스(Job Function)**를 기준으로 매핑한다.
- **잘못된 예:** `Read_User_Table`, `Write_User_Table` (기술 중심)
- **올바른 예:** `Customer_Support_Agent` (업무 중심 $\rightarrow$ 내부적으로 조회/수정 권한을 묶음)